A conference communication session refers to communication session between three or more participants that allows each participant to communicate simultaneously with multiple parties, which may also communicate among themselves. In a conference communication session each of the participants can communicate information including audio information, data and/or video information, or a combination thereof, with each of the other participants via a conference access device (CAD), such as wired or wireless communication device. For instance, one common type of conference communication session is a telephone call in which more than two participants participate in the audio portion of the call.
In a conference communication session, each participant can generate a stream of communication information (e.g., audio, data, video information) at their device that is to be communicated to other participants. For instance, if there are four participants P1, P2, P3, P4 in a conference communication session, then a device of participant P1 can generate communication information stream (CIS1), a device of participant P2 can generate communication information stream (CIS2), a device of participant P3 can generate communication information stream (CIS3), and a device of participant P4 can generate communication information stream (CIS4). Each CIS can include audio, data and/or video information. In this example, an entity that serves as the conference bridge for the conference communication session will mix the various CISs to generate a plurality of unique conferenced communication information streams (CCISs), and then communicates one of the unique CCISs to the device of each participant. As used herein, the term “conferenced communication information stream (CCIS)” refers to a communication stream transmitted to a participant's device that combines communication data generated by other devices participating in a communication session. The entity that performs the mixing must mix a number of CCISs equal to the number of participants and separately transmit a CCIS to each participant's device sot that each participant receives CISs from each of the other participants, but not their own CIS. For example, in the particular example provided above the entity will combine CIS2, CIS3, and CIS4 into a first CCIS1 and transmit the first CCIS1 to the device of participant P1. Likewise, the entity will combine CIS1, CIS3, and CIS4 into a second CCIS2 and transmit the second CCIS2 to the device of participant P2. will combine CIS1, CIS2, and CIS4 into a third CCIS3 and transmit the third CCIS3 to the device of participant P3, and will combine CIS1, CIS2, and CIS3 into a fourth CCIS4 and transmit the fourth CCIS4 to the device of participant P4. This way, each participant receives communication information streams (CISs) from all other participants, but does not receive their own CIS.
As will be described below, the entity that performs this mixing of CISs and that generates the various CCISs, can be either a centralized conference server in a “meet-me” conference communication session, or one of the devices that is actually participating in the conference communication session in an ad hoc conference communication session
A meet-me conference communication session allows the participants to call into and join the conference communication session themselves. In a meet-me conference communication session each participant is provided with a single common telephone number, bridge identifier and password (e.g., PIN code) prior to the start of the call. To access the conference communication session, participants call the common telephone number which has been assigned to a “conference bridge” that is instantiated at a “meet-me” conference server, and then enter a bridge identifier and password to connect their telephone to that “conference bridge.” The conference bridge then conferences or links multiple communications paths of multiple CADs together to allow simultaneous communications between the participants. In a meet me conference communication session, the conference server mixes the CISs and generates the various CCISs.
By contrast, an ad hoc conference communication session is designed so that a calling party calls the other participants and adds them to the conference communication session. In other words, the conference communication session is built by a single end-user by manually adding other conference participants to the session one-at-a-time. For example, a conventional three-way call is an ad-hoc conference as two people are conversing and then one of the two decides to add a third party manually. However, it should be appreciated that an ad-hoc conference communication session is not limited to three participants.
In a conventional ad hoc conference communication session it is common for one of the devices that is participating in the call to locally mix the CISs of the various participants in the communication session, and then retransmit a unique CCIS to each of the devices of the other participants. This requires the transmitting device to transmit multiple communication streams. “Locally” mixing the CISs at one of the devices places increased demands on the mixing device's hardware and can significantly reduce battery life. Moreover, transmitting multiple CCISs to each of the other devices of the other participants in the conference also consumes significant resources especially when the CCISs are transmitted wirelessly since this consumes significant “over-the-air” or radio resources. Under these circumstances, it would be desirable to transition from an ad hoc conference communication session to an infrastructure supported conference communication session so that mixing and replication of CISs and transmission of CCISs can be performed at a “meet-me” conference server.
Accordingly, it is desirable to provide improved systems and methods for automatically determining when to transition from an ad hoc conference communication session to an infrastructure supported conference communication session so that mixing and replication of CISs and subsequent transmission of the CCISs are performed at a conference server. Furthermore, other desirable features and characteristics of the present invention will become apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and the foregoing technical field and background.